To Reuse or To Be Reused

ions for component compositions can be domain-specific and areeither technical or consumer-related. The group of products (or systems) thatcan be built from technical abstractions forms a product family [115] (or sys-tem family). The group of products that can be built from consumer-relatedabstractions forms a product line. These consumer-related abstractions have anon-technical nature and correspond to the specific needs of a selected mar-ket. Thus, a product line is based on marketing strategy rather than on tech-nical similarities between products [51]. Observe that a product line neednot be a product family, although that is how its greatest benefits can beachieved [45, 51]. For example, the components in Figure 1.1 are abstractions in the domain oflanguage processing. The corresponding product family includes the ASF+SDFMeta-Environment and software renovations like goto elimination. A typicalproduct line would be a COBOL transformation factory, supporting the features goto elimination and copybook expansion. Individual product instances can beconfigured to feature one or more of these.The abstractions used in product families constitute the problem space. Thevariability of a product family is called the configuration space and defines thepossible group of products (i.e., its family members). Specifying individualfamily members by instantiating the variable part of a product family is per-formed using terminology (or abstractions) in the problem space. The solu-tion space contains the corresponding implementation components of a productfamily together with their possible configurations [51].Components implement an abstract-to-concrete mapping [11], or, in the ter-minology of [92], each abstraction specification has an abstraction realiza-tion (i.e., implementation). The same holds for layered abstractions. Con-sequently, the abstraction specification of a product family, constituting theproblem space, has a realization in the solution space.A challenge is to automate this abstract-to-concrete mapping such that animplementation can automatically be derived from a configuration in the prob-lem space. Generative programming is a software engineering paradigm thataims at this automated mapping [51]. 1.3 Component composition With software component reuse, software systems become composite systems(i.e., collections or compositions of application-specific and reusable compo-nents [11]), instead of monolithic systems. The functionality of such systemsis spread over the individual components and needs to be integrated to obtainthe desired behavior of the composite system.Components that form a system thus function as building blocks and shouldbe designed for integration. Integration can occur at different moments in time,each requiring a different integration mechanism. Some integration momentsthat can be distinguished on this integration time line include: Development-time integration It is concerned with assembling reuse reposi-tories containing all source modules of the components that constitute acomposite software system. Source integration is a technique for assem-bling such reuse repositories and will be discussed in more detail below. Pre compile-time integration It is concerned with merging reusable function-ality in the source code of the system under construction. The resultingsource can benefit from the type system of the programming languagebeing used, and from source code level optimizations. Pre compile-timetime integration may therefore reduce run-time overhead due to methodinvocations of small reused functionality. By combining it with layers ofabstractions, it can help to reduce the difficulty of scaling reuse librariesin size and feature variants (i.e., the library scaling problem [18]). Apromising technique for pre compile-time integration is Aspect Oriented Programming (AOP), which is a technique to weave functionality (as-pects) at explicit positions in source code (join points) [88].1 Compile-time integration Compile-time integration is the traditional way ofreusing functionality in applications. Reusable code is stored in librariesand linked with application-specific code to the final executable applica-tion. The functionality is accessed using function or method invocations.This kind of integration is language-specific and makes integration ofcomponents implemented in different languages difficult. Systems im-plemented in strongly typed languages can benefit from the type systemto assure that the functional composition is valid. Distribution-time integration Component integration at distribution-time isconcerned with packaging the components that form an application suchthat it can be distributed as a unit, and with the installation process ofthe application. This is also referred to as ‘content delivery’ [41]. Com-ponents can be distributed in either source or binary form. If componentsare distributed in source form, then distribution-time integration shouldalso address building the composite system. Package managers, such asRPM [6], are often used to build distributions of applications and to in-stall the applications on computer systems. Run-time integration Components in the form of executable programs or dy-namic loadable libraries can be integrated at run-time. A standard ex-ample is the Unix programming environment, where little tools, eachdesigned to perform a simple task, can be combined to form advancedprograms [87]. Integration in the Unix environment usually takes placein pipelines without type checking. More advanced run-time integra-tion techniques are offered by component architectures such as COM [24,124], CORBA [109], and EJB [102], or coordination architectures suchas the TOOLBUS [16]. Functionality is accessed via message passing andtype checking is based on component interface definitions, i.e., signaturesthat define the services offered by a component. Language-independenceis an important benefit of run-time integration, although it is not sup-ported by all run-time integration mechanisms. As an example, Figure 1.1 shows the composition of reusable components intwo different systems. The ASF+SDF Meta-Environment in Figure 1.1(a) is aninteractive system that interacts with its user via a graphical user interface. The‘goto elimination’ transformation depicted in Figure 1.1(b), on the other hand,is non-interactive. It transforms programs without further user interaction. Thecomponents of the ASF+SDF Meta-Environment are therefore integrated via abus architecture. Communication between components can take place in any 1Observe that weaving in AOP is not restricted to compile-time, but that it can occur at anytime, even at run-time. order and is accomplished by sending messages over the bus. For the trans-formation system, a pipeline architecture is used because all communicationbetween components takes place in a fixed left-to-right direction (the outputof a component to the left, forms the input of the component to its right).Despite these conceptually different integration techniques, the figure doesnot show how these components are integrated and when they have been in-tegrated. For instance, the pipeline might be implemented at run-time usingUnix pipes, or at compile-time using the functional composition: pretty-print(goto-elimination(parse(input))) Components are most often designed with a single integration mechanismsin mind. But for the construction of composite systems all integration mech-anisms can be combined. To make component-based software developmentsuccessful, it should not be difficult to construct composite software systemsfrom a wide range of components with different integration techniques. Tothat end, component interfaces [11, 116, 14] and standardized exchange for-mats are essential. Component interfaces serve to make software componentsinterchangeable (plug compatible) by hiding their implementations. Standard-ized exchange formats are inevitable to easily integrate different types of com-ponents (such as executable programs or library functions) anywhere on theintegration time line and independently of an implementation language.In addition to the integration techniques discussed thus far, which are con-cerned with functional integration, source integration is another technique thatis important for successful software reuse. It is performed at development-time,in advance of all other integration techniques and is concerned with mergingall source modules, all build instructions, and all compile-time configuration ofthe components that constitute a software system.Source integration is the opposite of decomposing a software system inreusable, independent components. From a software engineering perspective,decomposition complicates the software engineering process, because an appli-cation built from individual pieces is organized as a collection of componentsrather than as a single unit. Consequently, it is hard to develop, maintain,configure, and distribute such systems as a whole. The purpose of source in-tegration is to improve this situation by merging the source modules of reusedcomponents, as well as corresponding configuration knowledge and build in-structions, to reconstitute a single unit.Source integration is of particular importance when software reuse extendsproject or institute boundaries [83]. Typical examples are reuse of commercialoff-the-shelf (COTS) source components and open source software reuse [37].To promote such “third-party” software reuse, source integration techniquesincluding release management [71] and proper abstraction mechanisms in theform of source code components, are essential.A challenge of component composition is to automatically obtain all com-ponents that constitute a system, to configure them properly, and to assemble the software system from them. Knowing how to make these components fittogether is another key challenge. 1.4 Component granularity The granularity of a component is not well defined (e.g., it can be a function, amodule, or a complete software system), but it affects two important propertiesof a component: the payoff or benefit that is gained by reusing the component,and the general usefulness of the component. Development of reusable soft-ware components (development for reuse) may therefore serve two differentgoals: • Increasing the ratio of reused versus newly developed software (i.e., thereuse level [49, 118]) of composite software systems by developing com-ponents that provide high payoff. • Increasing the reuse of individual components by developing componentsof general usefulness. These goals can be formulated as: “to reuse or to be reused”.To meet the first goal (increasing the reuse level), large collections of reus-able components, providing high payoff to programmers using them, shouldbe available and easily accessible. Payoff, i.e., less lines of code that need to bewritten, can be increased by using large-scale components [18, 111].Unfortunately, large-scale components tend to be more specialized for theapplication domain (i.e., domain-specific). Consequently, the probability ofbeing reused decreases as components increase in size [18, 111, 131]. An-other problem is that large-scale components may themselves include moregeneral functionality, which does not come available for reuse outside the com-ponent [69].Thus, to meet the second goal (increasing the reuse of individual compo-nents), components should be made more generally applicable by restrictingtheir size and reducing their functionality.For example, Figure 1.1 shows examples of large-scale reusable componentsin the domain of language processing (e.g., parsers and compilers). The coarse-grained granularity of these high-level components hides lower level compo-nentising with less domain specificity. Since one might expect that commonal-ities also exist between the components within each application (for instance,for data exchange and communication in case of the ASF+SDF Meta-Environ-ment), the granularity of software reuse depicted in the figure is not optimal.To achieve fine-grained software reuse, components should be split in smallerreusable units, which have more general purpose applications. As an example,Figure 1.2, shows a more detailed view of the ASF+SDF Meta-Environmentwith fine-grained software reuse.